Closed Bug 1513447 Opened 6 years ago Closed 4 years ago

Assertion failure: false (MOZ_ASSERT_UNREACHABLE: Bullet and accessible are in sync already!), at src/accessible/html/HTMLListAccessible.cpp:90

Categories

(Core :: Disability Access APIs, defect, P3)

Product:
Core
Component:
Disability Access APIs
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
90 Branch
Tracking Flags:
Tracking Status
firefox-esr68 --- wontfix
firefox-esr78 --- wontfix
firefox65 --- wontfix
firefox66 --- wontfix
firefox78 --- wontfix
firefox79 --- wontfix
firefox80 --- wontfix
firefox85 --- wontfix
firefox86 --- wontfix
firefox87 --- wontfix
firefox88 --- wontfix
firefox89 --- wontfix
firefox90 --- fixed

People

(Reporter: tsmith, Assigned: eeejay)

References

(Blocks 1 open bug)

Details

(Keywords: assertion, testcase, Whiteboard: [fuzzblocker])

Attachments

(2 files, 1 obsolete file)

testcase.html
300 bytes, text/plain
Details
Bug 1513447 - Use generated marker elements for list bullet accessibles. r?Jamie
48 bytes, text/x-phabricator-request
Details | Review
Attached file testcase.html (obsolete) —
Reduced with m-c: BuildID=20181211213305 SourceStamp=ac7f3beb633340c6b3fea25059e8b8aa52b5fc8a Assertion failure: false (MOZ_ASSERT_UNREACHABLE: Bullet and accessible are in sync already!), at src/accessible/html/HTMLListAccessible.cpp:90 #0 mozilla::a11y::HTMLLIAccessible::UpdateBullet(bool) src/accessible/html/HTMLListAccessible.cpp:90:5 #1 nsBulletFrame::DidSetComputedStyle(mozilla::ComputedStyle*) src/layout/generic/nsBulletFrame.cpp:157:23 #2 nsIFrame::SetComputedStyle(mozilla::ComputedStyle*) src/layout/generic/nsIFrame.h:737:7 #3 nsIFrame::UpdateStyleOfOwnedChildFrame(nsIFrame*, mozilla::ComputedStyle*, mozilla::ServoRestyleState&, mozilla::Maybe<mozilla::ComputedStyle*> const&) src/layout/generic/nsFrame.cpp:10129:16 #4 nsBlockFrame::UpdatePseudoElementStyles(mozilla::ServoRestyleState&) src/layout/generic/nsBlockFrame.cpp:7198:5 #5 mozilla::UpdateFramePseudoElementStyles(nsIFrame*, mozilla::ServoRestyleState&) src/layout/base/RestyleManager.cpp:2489:41 #6 mozilla::RestyleManager::ProcessPostTraversal(mozilla::dom::Element*, mozilla::ComputedStyle*, mozilla::ServoRestyleState&, mozilla::ServoPostTraversalFlags) src/layout/base/RestyleManager.cpp:2790:7 #7 mozilla::RestyleManager::ProcessPostTraversal(mozilla::dom::Element*, mozilla::ComputedStyle*, mozilla::ServoRestyleState&, mozilla::ServoPostTraversalFlags) src/layout/base/RestyleManager.cpp:2765:13 #8 mozilla::RestyleManager::DoProcessPendingRestyles(mozilla::ServoTraversalFlags) src/layout/base/RestyleManager.cpp:2957:28 #9 mozilla::PresShell::DoFlushPendingNotifications(mozilla::ChangesToFlush) src/layout/base/PresShell.cpp:4033:39 #10 nsRefreshDriver::Tick(mozilla::layers::BaseTransactionId<mozilla::VsyncIdType>, mozilla::TimeStamp) src/layout/base/nsRefreshDriver.cpp:1757:18 #11 mozilla::RefreshDriverTimer::TickRefreshDrivers(mozilla::layers::BaseTransactionId<mozilla::VsyncIdType>, mozilla::TimeStamp, nsTArray<RefPtr<nsRefreshDriver> >&) src/layout/base/nsRefreshDriver.cpp:304:7 #12 mozilla::RefreshDriverTimer::Tick(mozilla::layers::BaseTransactionId<mozilla::VsyncIdType>, mozilla::TimeStamp) src/layout/base/nsRefreshDriver.cpp:321:5 #13 mozilla::VsyncRefreshDriverTimer::RefreshDriverVsyncObserver::TickRefreshDriver(mozilla::layers::BaseTransactionId<mozilla::VsyncIdType>, mozilla::TimeStamp) src/layout/base/nsRefreshDriver.cpp:646:16 #14 mozilla::VsyncRefreshDriverTimer::RefreshDriverVsyncObserver::NotifyVsync(mozilla::VsyncEvent const&) src/layout/base/nsRefreshDriver.cpp:546:9 #15 mozilla::layout::VsyncChild::RecvNotify(mozilla::VsyncEvent const&) src/layout/ipc/VsyncChild.cpp:65:16 #16 mozilla::layout::PVsyncChild::OnMessageReceived(IPC::Message const&) src/obj-firefox/ipc/ipdl/PVsyncChild.cpp:167:20 #17 mozilla::ipc::PBackgroundChild::OnMessageReceived(IPC::Message const&) src/obj-firefox/ipc/ipdl/PBackgroundChild.cpp:2788:28 #18 mozilla::ipc::MessageChannel::DispatchAsyncMessage(IPC::Message const&) src/ipc/glue/MessageChannel.cpp:2159:21 #19 mozilla::ipc::MessageChannel::DispatchMessage(IPC::Message&&) src/ipc/glue/MessageChannel.cpp:2086:9 #20 mozilla::ipc::MessageChannel::RunMessage(mozilla::ipc::MessageChannel::MessageTask&) src/ipc/glue/MessageChannel.cpp:1935:3 #21 mozilla::ipc::MessageChannel::MessageTask::Run() src/ipc/glue/MessageChannel.cpp:1966:13 #22 nsThread::ProcessNextEvent(bool, bool*) src/xpcom/threads/nsThread.cpp:1157:14 #23 NS_ProcessNextEvent(nsIThread*, bool) src/xpcom/threads/nsThreadUtils.cpp:468:10 #24 mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) src/ipc/glue/MessagePump.cpp:88:21 #25 MessageLoop::RunInternal() src/ipc/chromium/src/base/message_loop.cc:314:10 #26 MessageLoop::Run() src/ipc/chromium/src/base/message_loop.cc:289:3 #27 nsBaseAppShell::Run() src/widget/nsBaseAppShell.cpp:137:27 #28 XRE_RunAppShell() src/toolkit/xre/nsEmbedFunctions.cpp:915:20 #29 mozilla::ipc::MessagePumpForChildProcess::Run(base::MessagePump::Delegate*) src/ipc/glue/MessagePump.cpp:238:9 #30 MessageLoop::RunInternal() src/ipc/chromium/src/base/message_loop.cc:314:10 #31 MessageLoop::Run() src/ipc/chromium/src/base/message_loop.cc:289:3 #32 XRE_InitChildProcess(int, char**, XREChildData const*) src/toolkit/xre/nsEmbedFunctions.cpp:753:34 #33 content_process_main(mozilla::Bootstrap*, int, char**) src/browser/app/../../ipc/contentproc/plugin-container.cpp:49:28 #34 main src/browser/app/nsBrowserApp.cpp:265:18 #35 __libc_start_main /build/glibc-Cl5G7W/glibc-2.23/csu/../csu/libc-start.c:291 #36 _start (firefox+0x349f4)
Flags: in-testsuite?
Priority: -- → P3

This issue has been around for a long time and the fuzzers continue to trip over it. Marking as fuzzblocker (frequent and has been seen to interfere with reduction of other testcases). Jamie can you please find someone to have a look if possible? Thank you.

[1] https://firefox-source-docs.mozilla.org/tools/fuzzing/index.html#fuzz-blockers

status-firefox65: affected → wontfix
status-firefox66: affected → wontfix
status-firefox78: --- → wontfix
status-firefox79: --- → affected
status-firefox80: --- → affected
status-firefox-esr68: --- → wontfix
status-firefox-esr78: --- → affected
Whiteboard: [fuzzblocker]
Attached file testcase.html —

More reliable test case.

Attachment #9030633 - Attachment is obsolete: true
Flags: needinfo?(jteh)

A Pernosco session is available here: https://pernos.co/debug/dcllmINs7lMU010FOATCEQ/index.html

When a list's list-style-position changes from inside to outside or vice versa, the generated marker element is replaced without calling UpdateListBullet. This causes the list item to possibly have a wrong bullet state, specifically if the restyling also changes the list-style-type to none.

Assignee: nobody → eitan

In 1513447 there is a demonstrated instance in which the generated
marker is replaced with another one and throws the list item bullet
state into an unknown state. To remedy this we need to observe when such
elements are removed and added.

Instead of that, I opted to finally make the bullet accessible a real
content-backed accessible. This should help with other issues that pop
up when the list item overrides children management and keeps an
artificial accessible as its first child.

Pushed by eisaacson@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/5ff1cc0ecdb3 Use generated marker elements for list bullet accessibles. r=Jamie

https://hg.mozilla.org/mozilla-central/rev/5ff1cc0ecdb3

Status: NEW → RESOLVED
Closed: 4 years ago
status-firefox90: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 90 Branch
status-firefox86: affected → wontfix
status-firefox87: affected → wontfix
status-firefox88: --- → wontfix
status-firefox89: --- → wontfix
status-firefox-esr78: affected → wontfix
Flags: needinfo?(jteh)
Flags: in-testsuite?
Flags: in-testsuite+
Regressions: 1715151
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: